\section{NAT and HIP}
In this section, we introduce the network address translator
in context of Wi-Fi sharing, because almost every access point
assigns a private address to  mobile computers connected to it. 
\subsection{Introduction of NAT}\label{sec:nat}
Network
Address Translation as  defined in RFC 1631 \cite{rfc1631}, is a 
technology to connect more than one computers to the Internet using a
number of IP addresses which are equal to or smaller than the number of
computers in the network. Typically, in case of home and private use,
there is only one IP address which is used to connect to the
Internet. 

There are two kinds of NATs. The Basic NAT maps a set of private IP
addresses 1:1 to a set of public routable IP addresses. This kind of the NAT
only changes the IP addresses and is
often used in enterprise level where sufficient IP addresses are available.
The most common NAT is the Network Address Port Translation (NAPT) which
changes both the IP addresses and the port numbers. Normally there is only
one public IP address which is used at the NAPT. The NAPT maintains a table
of mappings between the $<$\texttt{private IP, local port}$>$ and
$<$\texttt{public IP, assigned port}$>$. The multiplexing and
demultiplexing of the traffic are based on the table.
In our thesis, the term NAT refers both to Network Address
Translator (NAT) and to Network Address and Port Translator (NAPT)
middleboxes.

The most important reason to use NAT is the depletion of the IPv4
addresses. Although the long-term solution for the problem is the
Internet Protocol Version 6 (IPv6), it will still take a
long time until the worldwide IPv6 deployment takes place. Additionally,
NAT provides also security features, because due to the nature
of address and port number mapping, only connections  initiated from inside
of the network are allowed. A NAT can also be used to facilitate the network
administration by using technologies like DHCP. 
\subsection{NAT and HIP}
The new namespace of Host Identity and the way how host peers communicate
with each other using HIP bring new problem concerning NAT boxes. HIP uses
protocol number 253 for the HIP control packets and 50 for ESP traffic.
To multiplex and demultiplex the traffic flow, a middlebox must use
\texttt{$<$dst ip, SPI, ESP$>$} to identify a traffic flow. But to get
these parameters, the middlebox must understand HIP and get involved 
in the Base Exchange and/or the Update process. But the most available NATs
are not HIP-aware and use 
$<$\texttt{src IP, dst IP, src port, dst port, protocol}$>$  to identify
traffic flows. 
Thus, for legacy NATs that do not understand HIP, normal HIP and ESP
traffic will be blocked.
\subsubsection{UDP-Encapsulation and NAT Traversal}
To achieve NAT traversal on legacy NATs, the HIP NAT Extensions
\cite{hip_nat} proposes to encapsulate the HIP control
packets and the IPsec BEET mode packets into UDP packets with specified
port numbers.
For this
purpose, the HIP header and ESP header are put into the payload of the UDP
packets.

According to \cite{hip_nat}, the Responder must listen to the UDP port
50500 to receive HIP control packets. It must also use the same UDP port
number as source port number. The Initiator can use 50500 as source port,
but
to support multiple Initiators behind a NAT to establish HIP association
with the same Responder, a randomized port number can also be used.
After a successful Base Exchange, both the Initiator and the Responder must
define  the UDP-encapsulated BEET mode as an IPsec mode for
the Security Associations. 

For ESP traffic, the UDP port 50500 is also recommended. The traffic is
demultiplexed on the basis of SPI and destination IP. 
